1. Field of the Invention
The present invention relates to a Broadband Wireless Access (BWA) communication system, and more particularly to a system and a method for performing a handover, that can minimize a service delay due to a pingpong effect.
2. Description of the Related Art
In a 4th generation (4G) communication system, which is the next generation communication system, research has been actively pursued to provide users with services having various qualities of service (QoS) at a transmission speed of about 10 Mbps. In particular, in the current 4G communication system, research has been actively pursued to support a high speed service capable of ensuring mobility and QoS in a BWA communication system such as a wireless local area network (LAN) system and a wireless metropolitan area network (MAN) system. A representative communication system of the 4G communication system is based on an IEEE (Institute of Electrical and Electronics Engineers) 802.16a communication system standard and an IEEE 802.16e communication system standard.
The IEEE 802.16a communication system and the IEEE 802.16e communication system are communication systems employing an Orthogonal Frequency Division Multiplexing (OFDM) scheme/an Orthogonal Frequency Division Access (OFDMA) scheme in order to support a broadband transmission network for a physical channel of the wireless MAN system. The IEEE 802.16a communication system only takes into consideration a single cell structure and stationary Subscriber Stations (SSs), which means the system does not in any way reflect the mobility of a SS. In contrast, the IEEE 802.16e communication system reflects the mobility of an SS in the IEEE 802.16a communication system. Here, an SS having the mobility is referred to as a Mobile Subscriber Station (MSS).
The structure of the IEEE 802.16e communication system will be described with reference to FIG. 1.
FIG. 1 is a block diagram showing the general structure of the IEEE 802.16e communication system.
Referring to FIG. 1, the IEEE 802.16e communication system has a multi-cell structure, that is, a cell 100 and a cell 150. Also, the IEEE 802.16e communication system includes a Base Station (BS) 110 controlling the cell 100, a BS 140 controlling the cell 150, and a plurality of MSSs 111, 113, 130, 151, and 153. The transmission/reception of signals between the BSs 110 and 140 and the MSSs 111, 113, 130, 151, and 153 is accomplished through an OFDM/OFDMA method. The MSS 130 from among the MSSs 111, 113, 130, 151, and 153 is located in a boundary area (i.e., handover area) between the cell 100 and the cell 150. When the MSS 130 moves into the cell 150 controlled by the BS 140 during the transmission/reception of signals with the BS 110, a serving BS of the MSS 130 changes from the BS 110 to the BS 140.
FIG. 2 is a flow diagram illustrating a general handover process by the request of the MSS in the IEEE 802.16e communication system.
Referring to FIG. 2, a serving BS 210 transmits a Mobile Neighbor Advertisement (MOB_NBR_ADV) message to an MSS 200 (step 211). The MOB_NBR_ADV message has a structure as shown in Table 1.
TABLE 1SyntaxSizeNotesMOB_NBR_ADV_message_Format( ) { Management Message Type=48 8 bits Operator ID24 bitsUnique IDassigned tothe operator Configuration Change Count 8 bits N_NEIGHBORS 8 bits For (j=0;j< N_NEIGHBORS;J++){  Neighbor BS-ID48 bits  Physical Frequency32 bits  TLV (Type Length Variable) EncodedVariableTLV specificNeighbor Information }}
As shown in Table 1, the MOB_NBR_ADV message includes a plurality of Information Elements (IEs), that is, the ‘Management Message Type’ representing the type of a transmitted message, the ‘Operator ID’ representing a network identifier (ID), the ‘Configuration Change Count’ representing the number of times by which a configuration changes, the ‘N_NEIGHBORS’ representing the number of neighbor BSs, the ‘Neighbor BS-ID’ representing IDs of the neighbor BSs, the ‘Physical Frequency’ representing the physical frequency of the neighbor BS, and the ‘TLV Encoded Neighbor Information’ representing extra information relating to the neighbor BS in addition to the information.
The MSS 200 may acquire information for the neighbor BSs by receiving the MOB_NBR_ADV message. Further, when the MSS 200 intends to scan the CINRs (Carrier to Interference and Noise Ratios) of the pilot channel signals transmitted from the neighbor BSs and the serving BS 210, the MSS 200 transmits a Mobile Scanning Interval Allocation Request (MOB_SCN-REQ) message to the serving BS 210 (step 213). The MOB_SCN-REQ message has a structure as shown in Table 2.
TABLE 2SyntaxSizeNotesMOB_SCN_REQ_message_Format( ) { Management Message Type=?8 bits Scan Duration12 bits Units are frames Start Frame4 bits}
As shown in Table 2, the MOB_SCN_REQ message includes a plurality of IEs, that is, the ‘Management Message Type’ representing the type of a transmitted message, the ‘Scan Duration’ representing a scan duration for the CINRs of the pilot channel signals transmitted from the neighbor BSs, and the ‘Start Frame’ representing a start frame for a scanning operation. The ‘Scan Duration’ is constructed by the frame. In Table 2, the ‘Management Message Type’ of the MOB_SCN_REQ message has not yet been defined (i.e., Management Message Type=undefined). Herein, since a time point at which the MSS 200 requests the scan has no direct connection with the scanning operation for the CINRs of the pilot channel signals, the detailed description will be omitted.
Meanwhile, the serving BS 210 having received the MOB_SCN_REQ message transmits a Mobile Scanning Interval Allocation Response (MOB_SCN_RSP) message, which includes information to be scanned by the MSS 200 and includes a scan duration having values except for 0, to the MSS 200 (step 215). The MOB_SCN_RSP message has a structure as shown in table 3.
TABLE 3SyntaxSizeNotesMOB_SCN_RSP_message_Format( ) { Management Message Type=?8 bits For(i=0;i<num_CIDs;i++){num_CIDs can bedetermined fromthe length of themessage {(foundin the generic MAC(Medium AccessControl) header)  CID16 bits basic CID of theMSS  Duration12 bits in frames  Estimated time for hand-over8 bits  Start Frame4 bits }}
As shown in Table 3, the MOB_SCN_RSP message includes a plurality of IEs, that is, the ‘Management Message Type’ representing the type of a transmitted message, the CID (Connection ID) of the MSS having transmitted the MOB_SCN_REQ message, the ‘Duration’, and the starting point of a scanning operation. In Table 3, the ‘Management Message Type’ of the MOB_SCN_RSP message to be transmitted has not yet been defined (i.e., Management Message Type=undefined), and the ‘Duration’ represents a duration for which the MSS 200 performs the pilot CINR scanning. A value of 0 for the Duration indicates a rejection of the scan request of the MSS 200.
The MSS 200 having received the MOB_SCN_RSP message containing the scanning information scans the CINRs of the pilot channel signals for neighbor BSs and the serving BS 210, which have been recognized through the reception of the MOB_NBR_ADV message, according to the parameters (i.e., Duration) contained in the MOB_SCN_RSP message (step 217).
After having completed the scanning for the CINRs of the pilot channel signals received from the neighbor BSs and the serving BS 210, when the MSS 200 determines to change the serving BS to which the MSS 200 currently belongs (step 219), that is, the MSS 200 determines to change the current serving BS to a new BS different from the BS 210, the MSS 200 transmits a Mobile Subscriber Station HandOver Request (MOB_MSSHO_REQ) message to the serving BS 210 (step 221). Herein, the new BS, which is not the serving BS currently including the MSS 200 but a BS capable of being a new serving BS through the handover of the MSS 200, is referred to as a target BS. The MOB_MSSHO_REQ message has a structure as shown in Table 4.
TABLE 4SyntaxSizeNotesMOB_MSSHO_REQ_message_Format( ) { Management Message Type=528 bits For (j=0;j< N_Recommended;J++) {N_Recommendedcan be derived from the knownlength of the message  Neighbor BS-ID48 bits   BS S/(N+1)8 bits  Service level prediction8 bits  Estimated HO Time8 bits }}
As shown in Table 4, the MOB_MSSHO_REQ message includes a plurality of IEs, that is, the ‘Management Message Type’ representing the type of a transmitted message, and a result obtained by scanning the CINRs of the pilot channel signals of the serving BS and the neighbor BSs by the MSS 200. In Table 4, the ‘N_Recommended’ represents the number of neighbor BSs having transmitted the pilot channel signals, which have CINRs larger than preset CINRs, on the basis of the scanning result for the CINRs of the pilot channel signals of each neighbor BS. The ‘N_Recommended’ represents the number of neighbor BSs recommended as BSs to which the MSS 200 could be handed over to. The MOB_MSSHO_REQ message includes the IDs for each neighbor BS, which are represented by the ‘N_Recommended’, the CINRs of the pilot channel signals for each neighbor BS, the service level predicted to be provided to the MSS 200 by the neighbor BSs, and the Estimated HO Time predicted as the starting time of handover after the neighbor BS is selected as a target BS.
When the serving BS 210 receives the MOB_MSSHO_REQ message transmitted from the MSS 200, the serving BS 210 detects a list of possible target BSs to which the MSS 600 could be handed over to by means of the ‘N_Recommended’ information of the received MOB_MSSHO_REQ message (step 223). For convenience of description, the list of target BSs to which the MSS 600 could be handed over to will be called a ‘handover-executable target BS list’. In FIG. 2, it is assumed that a first target BS 220 and a second target BS 230 exist in the handover-executable target BS list. Also, the handover-executable target BS list may include a plurality of target BSs. The serving BS 210 transmits a HO_PRE_NOTIFICATION message to the target BSs (i.e., the first target BS 220 and the second target BS 230) contained in the handover-executable target BS list (steps 225 and 227). The HO_PRE_NOTIFICATION message has a structure as shown in Table 5.
TABLE 5FieldSizeNotesGlobal Header152-bit For(j=0;j< Num Records;J++){ MSS unique identifier48-bit48-bit unique identifier used byMSS (as provided by the MSS orby the I-am-host-of message) Estimated Time to HO16-bitIn milliseconds, relative to thetime stamp, value 0 of thisparameter indicates that no actualHO is pending Required BW 8-bitBandwidth which is required byMSS (to guarantee minimumpacket data transmission) Required QoS 8-bitName of Service Classrepresenting AuthorizedQoSparamSet}Security fieldTBDA means to authenticate thismessageCRC field32-bitIEEE CRC-32
As shown in Table 5, the HO_PRE_NOTIFICATION message includes a plurality of IEs, that is, the Global Header commonly contained in messages exchanged between BSs in a backbone network, the MSS ID of the MSS 200 which is to be handed over to the first target BS 220 or the second target BS 230, the Estimated HO Time representing a time predicted as a start time of the handover by the MSS 200, the Required BW representing information on a bandwidth requested from the MSS 200 to a target BS to be a new serving BS, the Required QoS representing information on the level of a service to be provided to the MSS 200, etc. The bandwidth and the service level requested by the MSS 200 are identical to the predicted service level information recorded in the MOB_MSSHO_REQ message described in table 4.
The Global Header, which is commonly contained in the messages (equal to the HO-PRE-NOTIFICATION message) exchanged between the BSs in the backbone network, has a general structure as shown in Table 6.
TABLE 6FieldSizeNotesMessage Type=? 8-bitSender BS-ID48-bitBase station unique identifier (Same number asbroadcast on the DL_MAP message)Target BS-ID48-bitBase station unique identifier (Same number asbroadcast on the DL_MAP message)Time Stamp32-bitNumber of multiseconds since midnight GMT(set to 0xffffffff to ignore)Num Records16-bitNumber of MSS identity records
As shown in Table 6, the Global Header includes a plurality of IEs, that is, the ‘Message Type’ representing the type of a transmitted message, the Sender BS-ID representing a transmission BS transmitting the message, the Target BS-ID representing a reception BS receiving the message, and the Num Records representing the number of MSSs which are subjects of a record included in the message.
When the first target BS 220 and the second target BS 230 receive the HO_PRE_NOTIFICATION message from the serving BS 210, they transmit a HO_PRE_NOTIFICATION_RESPONSE message, which is a response message for the HO_PRE_NOTIFICATION message, to the serving BS 210 (steps 229 and 231). The HO_PRE_NOTIFICATION-RESPONSE message has a structure as shown in Table 7.
TABLE 7FieldSizeNotesGlobal Header152-bitFor(j=0;j< Num_Records;J++){ MSS unique identifier 48-bit48-bit unique identifier used byMSS (as provided by the MSSor by the I-am-host-of message) BW Estimated 8-bitBandwidth which is provided byBS (to guarantee minimumpacket data transmission) TBDhow to set this field QoS Estimated 8-bitQuality of Service levelUnsolicited Grant Service(UGS)Real-time Polling Service(rtPS)Non-Real-time Polling ServicenrtPS)Best Effort ACK/NACK 8 bitsAcknowledgement or Negativeacknowledgement1 is Acknowledgement whichmeans that the neighbor BSaccepts the HO-pre-notificationmessage from the serving BS0 is Negative Acknowledgementwhich means that the neighborBS may not accept the HO-pre-notification message from theserving BS}Security fieldTBDA means to authenticate thismessageCRC field 32-bitIEEE CRC-32
As shown in Table 7, the HO_PRE_NOTIFICATION_RESPONSE message includes a plurality of IEs, that is, the Global Header commonly included in the messages exchanged between the BSs in the backbone network as described in table 6, the MSS ID of an MSS which is to be handed over to target BSs, the ACK/NACK regarding whether the target BSs can perform handover according to the handover request of the MSS, and the bandwidth and service level information capable of being provided by each target BS when the MSS is handed over to each target BS.
Meanwhile, the serving BS 210 having received the HO_PRE_NOTIFICATION_RESPONSE messages from the first target BS 220 and the second target BS 230 analyzes the received HO_PRE_NOTIFICATION_RESPONSE message, and selects a target BS, which can optimally provide the bandwidth and the service level requested by the MSS 200 when the MSS 200 has been handed over, as a final target BS to which the MSS 200 is to be handed over. For instance, when it is assumed that the service level capable of being provided by the first target BS 220 is less than that requested by the MSS 200, and the service level capable of being provided by the second target BS 230 is identical to that requested by the MSS 200, the serving BS 210 selects the second target BS 230 as the final target BS to which the MSS 200 is to be handed over. Accordingly, the serving BS 210 transmits a HO_CONFIRM message to the second target BS 230 as a response message for the HO_PRE_NOTIFICATION_RESPONSE message (step 233). The HO_CONFIRM message has a structure as shown in Table 8.
TABLE 8FieldSizeNotesGlobal Header152-bitFor(j=0;j< Num_Records;J++){ MSS unique identifier 48-bit48-bit universal MAC address ofthe MSS (as provided to the BSon the RNG-REQ message) BW Estimated 8-bitBandwidth which is provided byBS (to guarantee minimumpacket data transmission) TBDhow to set this field QoS Estimated 8-bitQuality of Service levelUnsolicited Grant Service(UGS)Real-time Polling Service(rtPS)Non-Real-time Polling Service(nrtPS)Best Effort Service (BE)}Security fieldTBDA means to authenticate thismessageCRC field 32-bitIEEE CRC-32
As shown in Table 8, the HO_CONFIRM message includes a plurality of IEs, that is, the Global Header commonly included in the messages exchanged between the BSs in the backbone network as described in table 6, an MSS ID of an MSS which is to be handed over to the selected target BS, and the bandwidth and service level information capable of being provided from the target BS when the MSS is handed over to the selected target BS.
Also, the serving BS 210 transmits a BS HandOver Response (MOB_BSHO_RSP) message to the MSS 200 as a response message for the MOB_MSSHO_REQ message (step 235). Herein, the MOB_BSHO_RSP message includes information on the target BS to which the MSS 200 is to be handed over. The MOB_BSHO_RSP message has a structure as shown in Table 9.
TABLE 9SyntaxSizeNotesMOB_BSHO_RSP_message_Format( ) { Management Message Type=53 8 bits Estimated HO time 8 bits For (j=0;j< N_Recommended;J++){Neighbor base stationsshall be presented in anorder such that the first presentedis the one most recommended andthe last presented is the leastrecommended.N_Recommendedcan be derived from theknown length of the message.   Neighbor BS-ID48 bits  Service level prediction 8 bits }}
As shown in Table 9, the MOB_BSHO_RSP message includes a plurality of IEs, that is, the ‘Management Message Type’ representing the type of a transmitted message, the Estimated HO time predicted as a start time of a handover procedure, and the result for the target BSs selected by the serving BS. Further, the ‘N_Recommended’ of the MOB_BSHO_RSP message represents the number of target BSs, which satisfy the bandwidth and the service level requested by the MSS, among target BSs on the handover-executable target BS list. The MOB_BSHO_RSP message includes the IDs of each target BS represented by the ‘N_Recommended’ and the level of the service predicted to be provided from each target BS to the MSS. In FIG. 2, the MOB_HO_RSP message finally includes only information on the second target BS 230 from among the target BSs on the handover-executable target BS list. However, if there exist multiple target BSs capable of providing the bandwidth and service level requested by the MSS 200 from among the target BSs on the handover-executable target BS list, the MOB_BSHO_RSP message includes information on the multiple target BSs.
Further, the MSS 200 having received the MOB_BSHO_RSP message analyzes the ‘N_Recommended’ information contained in the MOB_BSHO_RSP message and selects the target BS to which the MSS 200 is to be handed over. Then, the MSS 200 having selected the target BS to which the MSS 200 is to be handed over transmits a Mobile Handover Indication (MOB_HO_IND) message to the serving BS 210 as a response message for the MOB_BSHO_RSP message (step 237). The MOB_HO_IND message has a structure as shown in Table 10.
TABLE 10SyntaxSizeNotesMOB_HO_IND_message_Format( ) { Management Message Type=54 8 bits reserved 6 bitsReserved; shall beset to zero HO_IND_type 2 bits00: Serviing BSrelease01: HO cancel10: HO reject11: reserved Target_BS_ID48 bitsApplicable onlywhenHO_IND_typeis set to 00 HMAC Tuple21 bytesSee 11.4.11}
As shown in Table 10, the MOB_HO_IND message includes a plurality of IEs, that is, the ‘Management Message Type’ representing the type of a transmitted message, the ‘HO_IND_type’ representing a determination, cancellation or rejection for handover to the final target BS selected by the MSS, the ‘Target_BS_ID’ representing an ID of the target BS selected by the MSS when the handover is determined, and the ‘HMAC Tuple ’ for authenticating the MOB_HO_IND message. In the ‘HO_IND_type’, when the MSS has determined to perform the handover to the final target BS, the MSS transmits the MOB_HO_IND message in which the ‘HO_IND_type’ has been set to 00. When the MSS has determined to cancel the handover to the final target BS, the MSS transmits the MOB_HO_IND message in which the ‘HO_IND_type’ has been set to 01. When the MSS has determined to reject the handover to the final target BS, the MSS transmits the MOB_HO_IND message in which the ‘HO_IND_type’ has been set to 10. The serving BS 210 having received the MOB_HO_IND message in which the ‘HO_IND_type’ has been set to 10 creates a new the handover-executable target BS list and then retransmits the MOB_BSHO_RSP message to the MSS 200.
Further, the serving BS 210 having received the MOB_HO_IND message in which the ‘HO_IND_type’ has been set to 00 recognizes that the MSS 200 is to be handed over to the target BS (i.e., second target BS 230) contained in the MOB_HO_IND message. Then, the serving BS 210 releases the connection information currently set with the MSS 200 or retains the connection information set with the MSS 200 over a preset time until a notification representing the complete end of the handover procedure is received from the target BS (i.e., second target BS 230) finally selected by the MSS 200 (step 239). In this way, after the MSS 200 has transmitted the MOB_HO_IND message to the serving BS 210, the MSS 200 performs a remaining handover operation with the second target BS 230.
FIG. 3 is a flow diagram illustrating a general handover process by the request of the BS in the IEEE 802.16e communication system.
Before a description about FIG. 3 is given, the handover process by the request of the BS occurs when the BS is overloaded and requires a load sharing for dispersing the load of the BS to neighbor BSs, or the BS must cope with the change of the uplink status of an MSS. Referring to FIG. 3, a serving BS 310 transmits a MOB_NBR_ADV message to an MSS 300 (step 311). The MSS 300 may obtain information on the neighbor BSs by receiving the MOB_NBR_ADV message.
When the serving BS 310 detects the need for a handover of the MSS 300 controlled by the serving BS 310 (step 313), the serving BS 310 transmits the HO_PRE_NOTIFICATION messages to the neighbor BSs (steps 315 and 317). Herein, the HO_PRE_NOTIFICATION message includes information for the bandwidth and the service level which must be provided to the MSS 300 from a target BS which is to be a new serving BS of the MSS 300. In FIG. 3, it is assumed that the neighbor BSs of the serving BS 310 are a first target BS 320 and a second target BS 330.
After receiving the HO_PRE_NOTIFICATION messages, each of the first target BS 320 and the second target BS 330 transmit the HO_PRE_NOTIFICATION_RESPONSE message to the serving BS 310 as a response message of the HO_PRE_NOTIFICATION message (steps 319 and 321). The HO_PRE_NOTIFICATION_RESPONSE message includes the ACK/NACK, which represents if the target BSs can perform the handover requested by the serving BS 310, and the bandwidth and service level information capable of being provided to the MSS 300 as described in Table 7.
After the serving BS 310 receives the HO_PRE_NOTIFICATION_RESPONSE messages from the first target BS 320 and the second target BS 330, the serving BS 310 selects the target BSs capable of providing the bandwidth and service level requested by the MSS 300. For example, when it is assumed that the service level capable of being provided by the first target BS 320 is less than that requested by the MSS 300, and the service level capable of being provided by the second target BS 330 is equal to that requested by the MSS 300, the serving BS 310 selects the second target BS 330 as a final target BS to which the MSS 300 can be handed over. After selecting the second target BS 330 as the target BS to which the MSS 300 can be handed over, the serving BS 310 transmits a Mobile BS HandOver Request (MOB_BSHO_REQ) message including the handover-executable target BS list to the MSS 300 (step 323). The handover-executable target BS list may include multiple target BSs. The MOB_BSHO_REQ message has a structure as shown in table 11.
TABLE 11SyntaxSizeNotesMOB_BSHO_REQ_message_Format( ) { Management Message Type=518 bits For (j=0;j< N_Recommended;J++){N_Recom-mended canbe derivedfrom the knownlength of themessage  Neighbor BS-ID48 bits    Service level prediction8 bits }}
As shown in Table 11, the MOB_BSHO_REQ message includes a plurality of IEs, that is, the ‘Management Message Type’ representing the type of a transmitted message, and information on the target BSs selected by the serving BS 310. In table 11, the ‘N_Recommended’ represents the number of neighbor BSs selected as the target BSs to which the MSS 300 can be handed over by the serving BS 310. Further, the MOB_BSHO_REQ message includes the IDs for each neighbor BS, which are represented by the ‘N_Recommended’, and the information on the bandwidth and service level capable of being provided to the MSS 300 from the neighbor BSs.
The MSS 300 having received the MOB_BSHO_REQ message recognizes that the handover has been requested by the serving BS 310, and selects a final target BS to which the MSS 300 is to be handed over with reference to the ‘N_Recommended’ information contained in the MOB_BSHO_REQ message. Before selecting the final target BS, when the MSS 300 intends to scan the CINRs of the pilot channel signals transmitted from the serving BS 310 and the neighbor BSs, the MSS 300 transmits the MOB_SCN_REQ message to the serving BS 310 (step 325). Herein, since a point in time at which the MSS 300 requests the scan has no direct connection to the scanning operation for the CINRs of the pilot channel signals, the detailed description will be omitted. The serving BS 310 having received the MOB_SCN_REQ message transmits the MOB_SCN_RSP message including information to be scanned by the MSS 300 to the MSS 300 (step 327). The MSS 300 having received the MOB_SCN_RSP message including the scanning information scans the CINRs of the pilot channel signals for the neighbor BSs, which have been recognized through the reception of the MOB_NBR_ADV message, the target BSs to which the MSS 300 can be handed over, which have been recognized through the reception of the MOB_BSHO_REQ message, and the serving BS 310 according to the parameters (i.e., Duration) included in the MOB_SCN_RSP message (step 329).
After selecting the final target BS to which the MSS 300 is to be handed over, the MSS 300 transmits the MOB_MSSHO_RSP message the serving BS 310 as a response message for the MOB_BSHO_REQ message (step 331). The MOB_MSSHO_RSP message has a structure as shown in Table 12.
TABLE 12SyntaxSizeNotesMOB_MSSHO_RSP_message_Format( ) { Management Message Type=548 bits Estimated HO Time8 bits For (j=0;j< N_Recommended;J++){N_Recom-mended can bederived fromthe knownlength of themessage  Neighbor BS-ID48 bits   BS S/(N+1)8 bits }}
As shown in Table 12, the MOB_MSSHO_RSP message includes a plurality of IEs, that is, the ‘Management Message Type’ representing the type of a transmitted message, the Estimated HO Time predicted as a start time of the handover procedure, and information on the target BSs selected by the MSS. In table 12, the ‘N_Recommended’ represents the number of the neighbor BSs selected as the target BSs to which the MSS can be handed over. Further, the MOB_MSSHO_RSP message includes the IDs for each neighbor BS, which are represented by the ‘N_Recommended’, and the information on the service level capable of being provided to the MSS from the neighbor BSs.
The serving BS 310 transmits the HO_CONFIRM message to the neighbor BS selected as the final target BS by the MSS 300 in response to the HO_PRE_NOTIFICATION-RESPONSE message (step 333). The MSS 300 having selected the final target BS transmits the MOB_HO_IND message in which the ‘HO_IND_type’ has been set to 00 to the serving BS 310 (step 335). After receiving the MOB_HO_IND message, the serving BS 310 recognizes again that the MSS 300 is to be handed over to the final target BS included in the MOB_HO_IND message. Then, the serving BS 310 releases connection information currently set with the MSS 300, or retains the connection information set with the MSS 300 during a preset time until a notification representing the completion of the handover procedure is received from the target BS (i.e., second target BS 330) finally selected by the MSS 200 (step 337). In this way, after the MSS 300 has transmitted the MOB_HO_IND message to the serving BS 310, the MSS 300 performs a remaining handover operation with the second target BS 330.
FIG. 4 is a flow diagram illustrating a general network reentry process according to the handover of the MSS in the IEEE 802.16e communication system.
Referring to FIG. 4, an MSS 400 changes the connection to a final target BS 450 and acquires the downlink synchronization with the final target BS 450. Then, the MSS 400 receives a DownLink_MAP (DL_MAP) message transmitted from the final target BS 450 (step 411). The DL_MAP message includes parameters relating to a downlink of the final target BS 450. The MSS 400 receives an UpLink_MAP (UL_MAP) message transmitted from the final target BS 450 (step 413). The UL_MAP message is a message including parameters relating to an uplink of the final target BS 450. Further, the UL_MAP message includes an FAST_UL_RANGING_IE which the final target BS 450 has assigned to support an FAST_UL_RANGING of the MSS 400 performing the handover. The reason for the final target BS 450 to assign the FAST_UL_RANGING IE to the MSS 400 is to minimize a delay which may occur when the MSS 400 performs the handover. Accordingly, the MSS 400 may perform an initial ranging with the final target BS 450 in a contention-free scheme according to the FAST_UL_RANGING_IE. Herein, the FAST UL RANGING IE included in the UL_MAP message is as shown in Table 13.
TABLE 13SyntaxSizeNotesFast_UL_ranging_IE { MAC address48 bits MSS MAC address asprovided on theRNG_REQ message oninitial system entry. UIUC4 bitsUIUC = 15. A four-bitcode used to define thetype of uplink access andthe burst type associatedwith that access. OFDM Symbol offset10 bits The offset of the OFDMsymbol in which theburst starts, the offsetvalue is defined in unitsof OFDM symbols and isrelevant to theAssociation Start Timefield given in theUL_MAP message. Subchannel offset6 bitsThe lowest indexOFDMA subchannelused for carrying theburst, starting fromsubchannel 0. No OFDM Symbol10 bits The number of OFDMsymbols that are used tocarry the UL Burst. No Subchannels6 bitsThe number of OFDMAsubchannels withsubsequent indexes, usedto carry the burst. Reserved4 bits}
The FAST_UL_RANGING_IE in Table 13 includes information for the MAC address of an MSS which is to obtain a ranging opportunity, the Uplink Interval Usage Code (UIUC) for providing region information including a start offset value for the FAST_UL_RANGING, and the offset of a ranging opportunity interval of a contention-free scheme/the number of symbols/the number of subchannels, which are assigned to the MSS 400, etc. The MAC address of the MSS 400 is notified to the final target BS 450 through a message such as the HO_PRE_NOTIFICATION message, the HO_PRE_NOTIFICATION_RESPONSE message and the HO_CONFIRM message exchanged between the serving BS and the final target BS in the backbone network in the handover process described in FIGS. 2 and 3.
The MSS 400 having received the UL_MAP message transmits a Ranging Request (RNG_REQ) message to the final target BS 450 according to the FAST_UL_RANGING_IE (step 415). The final target BS 450 having received the RNG_REQ message transmits a Ranging Response (RNG_RSP) message including the information for compensating for a frequency, a time and a transmit power for the ranging to the MSS 400 (step 417).
The MSS 400 and the final target BS 450 having completed the initial ranging perform a re-authorization operation (MSS RE_AUTHORIZATION) for the MSS 400 (step 419). In the performance of the re-authorization operation, when a security context exchanged between a serving BS to which the MSS 400 previously belongs and the final target BS 450 has not changed, the final target BS 450 uses the security context as is. A backbone network message for providing the security context information of the MSS 400, that is, an MSS-information-response (MSS_INFO_RSP) message has a structure as shown in Table 14.
TABLE 14FieldSizeNotesGlobal Header152-bit For (j=0;j< Num_Records;J++){ MSS unique identifier48-bit48-bit unique identifier usedby MSS (as provided by theMSS or by the I-am-host-ofmessage) N_NSIENumber of Network ServiceInformation Elements For (k=0;k< N_NSIEk++){  Field Size16-bitSize of TLV encodedinformation field below  TLV encodedVariableTLV information as followed  informationon a DSA-REQ MACmessage } N_SAIENumber of SecurityAssociation InformationElements For (k=0;k< N_SAIE; k++){  Field Size16-bitSize of TLV encodedinformation field below  TLV encodedVariableTLV information as followed  informationon a PKM-xxx MAC message } N_MSS_CAPNumber of MSS Capabilities For (k=0;k<N_MSS_CAP; k++){  Field Size16-bitSize of TLV encodedinformation field below  TLV encodedVariableTLV information as followed  informationon a SBC-REQ MACmessage } TLV encodedVariableTLV information as followed informationon a SBC-REQ MACmessage}Security fieldTBDA means to authenticate thismessageCRC field32-bitIEEE CRC-32
As shown in Table 14, the MSS_INFO_RSP message includes the ID information of MSSs registered in the serving BS, the security context information such as Security Association Information for each MSS, the Network Service Information for each MSS, the capability information of each MSS, etc.
When the re-authorization operation has been completed for the final target BS 450 and the MSS 400, the MSS 400 transmits a Registration Request (REG_REQ) message to the final target BS 450 (step 421). The REG_REQ message includes the registration information of the MSS 400. The final target BS 450 transmits a Registration Response (REG_RSP) message to the MSS 400 in response to the REG_REQ message (step 423). The final target BS 450 detects the registration information of the MSS 400 contained in the received REG_REQ message, thereby recognizing that the MSS 400 is an MSS having performed the handover. Accordingly, the final target BS 450 maps the connection setup information of the MSS 400 in the previous serving BS with the connection setup information of the MSS 400 in the final target BS 450. Further, the final target BS 450 inserts a TLV value, which is used for resetting a service flow capable of being actually received, into the MSS_INFO_RSP message and then transmits the MSS_INFO_RSP message to the MSS 400. Table 15 shows the structure of the TLV including mapping information for connection setup in the serving BS and the final target BS 450.
TABLE 15TypeLengthName(1 byte)(1 byte)Value (Variable-length)New_CID2.12New CID after hand-over to new BSOld_CID2.22Old CID before hand-over from oldBSConnection2.3Varia-If any of the service flow parametersInfoblechange, then those service flowparameters and CS parameter encodingTLVs that have changed will be added.Connection_Info is a compound TLVvalue that encapsulates the ServiceFlow Parameters and the CS parameterthat have changed for the service. Allthe rules and settings that apply to theparameters when used in the DSC-RSPmessage apply to the contentsencapsulated in this TLV.
In Table 15, the TLV contained in the REG_RSP message provides a CID used in the serving BS before the MSS 400 performs the handover, and the CID information which is to be used in the final target BS 450 after the MSS 400 has performed the handover. Further, when the final target BS 450 provides a service different from a service flow provided from the serving BS before the handover, the TLV includes information for any changed service parameters.
The MSS 400 completes the network reentry procedure with the final target BS 450 and performs a normal communication service through the final target BS 450 (step 425).